home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1847.txt < prev    next >
Text File  |  1997-04-01  |  24KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Galvin
  8. Request For Comments: 1847                                     S. Murphy
  9. Category: Standards Track                    Trusted Information Systems
  10.                                                               S. Crocker
  11.                                                          CyberCash, Inc.
  12.                                                                 N. Freed
  13.                                             Innosoft International, Inc.
  14.                                                             October 1995
  15.  
  16.  
  17.                      Security Multiparts for MIME:
  18.                 Multipart/Signed and Multipart/Encrypted
  19.  
  20. Status of this Memo
  21.  
  22.    This document specifies an Internet standards track protocol for the
  23.    Internet community, and requests discussion and suggestions for
  24.    improvements.  Please refer to the current edition of the "Internet
  25.    Official Protocol Standards" (STD 1) for the standardization state
  26.    and status of this protocol.  Distribution of this memo is unlimited.
  27.  
  28. Abstract
  29.  
  30.    This document defines a framework within which security services may
  31.    be applied to MIME body parts.  MIME, an acronym for "Multipurpose
  32.    Internet Mail Extensions", defines the format of the contents of
  33.    Internet mail messages and provides for multi-part textual and non-
  34.    textual message bodies.  The new content types are subtypes of
  35.    multipart: signed and encrypted.  Each will contain two body parts:
  36.    one for the protected data and one for the control information
  37.    necessary to remove the protection.  The type and contents of the
  38.    control information body parts are determined by the value of the
  39.    protocol parameter of the enclosing multipart/signed or
  40.    multipart/encrypted content type, which is required to be present.
  41.  
  42. Table of Contents
  43.  
  44.    1.  Introduction ..............................................    2
  45.    2.  Definition of Security Subtypes of Multipart ..............    2
  46.    2.1   Definition of Multipart/Signed ..........................    3
  47.    2.2   Definition of Multipart/Encrypted .......................    6
  48.    3.  Definition of Control Information Content Types ...........    9
  49.    4.  Definition of Key Management Content Types ................    9
  50.    5.  Security Considerations ...................................   10
  51.    6.  Acknowledgements ..........................................   10
  52.    7.  References ................................................   10
  53.    8.  Authors' Addresses ........................................   11
  54.  
  55.  
  56.  
  57.  
  58. Galvin, et al               Standards Track                     [Page 1]
  59.  
  60. RFC 1847                  Security Multiparts               October 1995
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    An Internet electronic mail message consists of two parts: the
  66.    headers and the body.  The headers form a collection of field/value
  67.    pairs structured according to STD 11, RFC 822 [1], whilst the body,
  68.    if structured, is defined according to MIME [2].  The basic MIME
  69.    specification does not provide specific security protection.
  70.  
  71.    This document defines a framework whereby security protection
  72.    provided by other protocols may be used with MIME in a complementary
  73.    fashion.  By itself, it does not specify security protection.  A MIME
  74.    agent must include support for both the framework defined here and a
  75.    mechanism to interact with a security protocol defined in a separate
  76.    document.  The resulting combined service provides security for
  77.    single-part and multi-part textual and non-textual messages.
  78.  
  79.    The framework is provided by defining two new security subtypes of
  80.    the MIME multipart content type: signed and encrypted.  In each of
  81.    the security subtypes, there are exactly two related body parts: one
  82.    for the protected data and one for the control information.  The type
  83.    and contents of the control information body parts are determined by
  84.    the value of the protocol parameter of the enclosing multipart/signed
  85.    or multipart/encrypted content type, which is required to be present.
  86.    By registering new values for the required protocol parameter, the
  87.    framework is easily extended to accommodate a variety of protocols.
  88.  
  89.    A MIME agent that includes support for this framework will be able to
  90.    recognize a security multipart body part and to identify its
  91.    protected data and control information body parts.  If the value of
  92.    the protocol parameter is unrecognized the MIME agent will not be
  93.    able to process the security multipart.  However, a MIME agent may
  94.    continue to process any other body parts that may be present.
  95.  
  96. 2.  Definition of Security Subtypes of Multipart
  97.  
  98.    The multipart/signed content type specifies how to support
  99.    authentication and integrity services via digital signature.  The
  100.    control information is carried in the second of the two required body
  101.    parts.
  102.  
  103.    The multipart/encrypted content type specifies how to support
  104.    confidentiality via encryption.  The control information is carried
  105.    in the first of the two required body parts.
  106.  
  107.    A three-step process is described for the origination and reception
  108.    of the multipart/signed and multipart/encrypted contents.  The
  109.    details of the processing performed during each step is left to be
  110.    specified by the security protocol being used.
  111.  
  112.  
  113.  
  114. Galvin, et al               Standards Track                     [Page 2]
  115.  
  116. RFC 1847                  Security Multiparts               October 1995
  117.  
  118.  
  119. 2.1.  Definition of Multipart/Signed
  120.  
  121.    (1)  MIME type name: multipart
  122.  
  123.    (2)  MIME subtype name: signed
  124.  
  125.    (3)  Required parameters: boundary, protocol, and micalg
  126.  
  127.    (4)  Optional parameters: none
  128.  
  129.    (5)  Security considerations: Must be treated as opaque while in
  130.         transit
  131.  
  132.    The multipart/signed content type contains exactly two body parts.
  133.    The first body part is the body part over which the digital signature
  134.    was created, including its MIME headers.  The second body part
  135.    contains the control information necessary to verify the digital
  136.    signature.  The first body part may contain any valid MIME content
  137.    type, labeled accordingly.  The second body part is labeled according
  138.    to the value of the protocol parameter.
  139.  
  140.    The attribute token for the protocol parameter is "protocol", i.e.,
  141.  
  142.     parameter := "protocol" "=" value
  143.  
  144.    The value token is comprised of the type and sub-type tokens of the
  145.    Content-Type: header of the second body part, i.e.,
  146.  
  147.     value := <"> type "/" subtype <">
  148.  
  149.    where the type and subtype tokens are defined by the MIME [2]
  150.    specification.  The semantics of the protocol parameter are defined
  151.    according to its value.
  152.  
  153.    The attribute token for the micalg parameter is "micalg", i.e.,
  154.  
  155.     parameter := "micalg" "=" value
  156.  
  157.    The Message Integrity Check (MIC) is the name given to the quantity
  158.    computed over the body part with a message digest or hash function,
  159.    in support of the digital signature service.  Valid value tokens are
  160.    defined by the specification for the value of the protocol parameter.
  161.    The value may be a comma (",") separated list of tokens, indicating
  162.    the use of multiple MIC algorithms.  As a result, the comma (",")
  163.    character is explicitly excluded from the list of characters that may
  164.    be included in a token used as a value of the micalg parameter.  If
  165.    multiple MIC algorithms are specified, the purpose and use of the
  166.    multiple algorithms is defined by the protocol.  If the MIC algorithm
  167.  
  168.  
  169.  
  170. Galvin, et al               Standards Track                     [Page 3]
  171.  
  172. RFC 1847                  Security Multiparts               October 1995
  173.  
  174.  
  175.    is also specified in the control information and the value there does
  176.    not agree with the value in this parameter, it must be treated as an
  177.    error.
  178.  
  179.     NOTE: The presence of the micalg parameter on the
  180.     multipart/signed content type header is explicitly intended to
  181.     support one-pass processing.  MIME implementations may locate
  182.     the second body part by inputting the first body part and
  183.     computing the specified MIC values until the boundary
  184.     identifying the second body part is found.
  185.  
  186.    The entire contents of the multipart/signed container must be treated
  187.    as opaque while it is in transit from an originator to a recipient.
  188.    Intermediate message transfer agents must not alter the content of a
  189.    multipart/signed in any way, including, but not limited to, changing
  190.    the content transfer encoding of the body part or any of its
  191.    encapsulated body parts.
  192.  
  193.    The signature in a multipart/signed only applies to the material that
  194.    is actually within the multipart/signed object.  In particular, it
  195.    does not apply to any enclosing message material, nor does it apply
  196.    to entities that are referenced (e.g. via a MIME message/external-
  197.    body) by rather than included in the signed content.
  198.  
  199.    When creating a multipart/signed body part, the following sequence of
  200.    steps describes the processing necessary.  It must be emphasized that
  201.    these steps are descriptive, not prescriptive, and in no way impose
  202.    restrictions or requirements on implementations of this
  203.    specification.
  204.  
  205.    (1)  The content of the body part to be protected is prepared
  206.         according to a local convention.  The content is then
  207.         transformed into a MIME body part in canonical MIME format,
  208.         including an appropriate set of MIME headers.
  209.  
  210.         In addition, if the multipart/signed object is EVER to be
  211.         transferred over the standard Internet SMTP infrastructure, the
  212.         resulting MIME body is constrained to 7 bits -- that is, the use
  213.         of material requiring either 8bit or binary
  214.         content-transfer-encoding is NOT allowed.  Such 8bit or binary
  215.         material MUST be encoded using either the quoted-printable or
  216.         base64 encodings.
  217.  
  218.         This requirement exists because it is not generally possible,
  219.         given the current characteristics of Internet SMTP, for a
  220.         message originator to guarantee that a message will travel only
  221.         along paths capable of carrying 8bit or binary material.
  222.  
  223.  
  224.  
  225.  
  226. Galvin, et al               Standards Track                     [Page 4]
  227.  
  228. RFC 1847                  Security Multiparts               October 1995
  229.  
  230.  
  231.         SMTP clients normally have the option of either converting the
  232.         message to eliminate the use of 8bit or binary encoding or
  233.         returning a nondelivery notification to the originator.
  234.         However, conversion is not viable in the case of signed objects
  235.         since conversion would necessarily invalidate the signature.
  236.         This leaves a nondelivery notification as the only available
  237.         option, which is not acceptable.
  238.  
  239.    (2)  The body part (headers and content) to be digitally signed is
  240.         prepared for signature according to the value of the protocol
  241.         parameter.  The MIME headers of the signed body part are
  242.         included in the signature to protect the integrity of the MIME
  243.         labeling of the data that is signed.
  244.  
  245.    (3)  The prepared body part is made available to the signature creation
  246.         process according to a local convention.  The signature creation
  247.         process must make available to a MIME implementation two data
  248.         streams: the control information necessary to verify the
  249.         signature, which the MIME implementation will place in the second
  250.         body part and label according to the value of the protocol
  251.         parameter, and the digitally signed body part, which the MIME
  252.         implementation will use as the first body part.
  253.  
  254.    When receiving a multipart/signed body part, the following sequence
  255.    of steps describes the processing necessary to verify the signature
  256.    or signatures.  It must be emphasized that these steps are
  257.    descriptive, not prescriptive, and in no way impose restrictions or
  258.    requirements on implementations of this specification.
  259.  
  260.    (1)  The first body part and the control information in the second body
  261.         part must be prepared for the signature verification process
  262.         according to the value of the protocol parameter.
  263.  
  264.    (2)  The prepared body parts must be made available to the signature
  265.         verification process according to a local convention.  The
  266.         signature verification process must make available to the MIME
  267.         implementation the result of the signature verification and the
  268.         body part that was digitally signed.
  269.  
  270.             NOTE: The result of the signature verification is likely to
  271.             include a testament of the success or failure of the
  272.             verification.  Also, in the usual case, the body part
  273.             returned after signature verification will be the same as
  274.             the body part that was received.  We do not insist that
  275.             this be the case to allow for protocols that may modify the
  276.             body part during the signature processing.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Galvin, et al               Standards Track                     [Page 5]
  283.  
  284. RFC 1847                  Security Multiparts               October 1995
  285.  
  286.  
  287.    (3)  The result of the signature verification process is made available
  288.         to the user and the MIME implementation continues processing with
  289.         the verified body part, i.e., the body part returned by the
  290.         signature verification process.
  291.  
  292.    The following example is an illustration of a multipart/signed body
  293.    part.  It is necessarily incomplete since the control information is
  294.    defined by the security protocol, which must be specified in a
  295.    separate document.
  296.  
  297.     Content-Type: multipart/signed; protocol="TYPE/STYPE";
  298.             micalg="MICALG"; boundary="Signed Boundary"
  299.  
  300.     --Signed Boundary
  301.     Content-Type: text/plain; charset="us-ascii"
  302.  
  303.     This is some text to be signed although it could be
  304.     any type of data, labeled accordingly, of course.
  305.  
  306.     --Signed Boundary
  307.     Content-Type: TYPE/STYPE
  308.  
  309.     CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
  310.  
  311.     --Signed Boundary--
  312.  
  313. 2.2.  Definition of Multipart/Encrypted
  314.  
  315.    (1)  MIME type name: multipart
  316.  
  317.    (2)  MIME subtype name: encrypted
  318.  
  319.    (3)  Required parameters: boundary, protocol
  320.  
  321.    (4)  Optional parameters: none
  322.  
  323.    (5)  Security considerations: none
  324.  
  325.    The multipart/encrypted content type contains exactly two body parts.
  326.    The first body part contains the control information necessary to
  327.    decrypt the data in the second body part and is labeled according to
  328.    the value of the protocol parameter.  The second body part contains
  329.    the data which was encrypted and is always labeled
  330.    application/octet-stream.
  331.  
  332.    The attribute token for the protocol parameter is "protocol", i.e.,
  333.  
  334.     parameter := "protocol" "=" value
  335.  
  336.  
  337.  
  338. Galvin, et al               Standards Track                     [Page 6]
  339.  
  340. RFC 1847                  Security Multiparts               October 1995
  341.  
  342.  
  343.    The value token is comprised of the type and sub-type tokens of the
  344.    Content-Type: header of the first body part, i.e.,
  345.  
  346.     value := <"> type "/" subtype <">
  347.  
  348.    where the type and subtype tokens are defined by the MIME [2]
  349.    specification.  The semantics of the protocol parameter are defined
  350.    according to its value.
  351.  
  352.    When creating a multipart/encrypted body part, the following sequence
  353.    of steps describes the processing necessary.  It must be emphasized
  354.    that these steps are descriptive, not prescriptive, and in no way
  355.    impose restrictions or requirements on implementations of this
  356.    specification.
  357.  
  358.    (1)  The contents of the body part to be protected is prepared according
  359.         to a local convention.  The contents are then transformed into a
  360.         MIME body part in canonical MIME format, including an appropriate
  361.         set of MIME headers.
  362.  
  363.    (2)  The body part (headers and content) to be encrypted is prepared for
  364.         encryption according to the value of the protocol parameter.  The
  365.         MIME headers of the encrypted body part are included in the
  366.         encryption to protect from disclosure the MIME labeling of the
  367.         data that is encrypted.
  368.  
  369.    (3)  The prepared body part is made available to the encryption process
  370.         according to a local convention.  The encryption process must make
  371.         available to a MIME implementation two data streams: the control
  372.         information necessary to decrypt the body part, which the MIME
  373.         implementation will place in the first body part and label
  374.         according to the value of the protocol parameter, and the
  375.         encrypted body part, which the MIME implementation will place in
  376.         the second body part and label application/octet-stream.  Thus,
  377.         when used in a multipart/encrypted, the application/octet-stream
  378.         data is comprised of a nested MIME body part.
  379.  
  380.    When receiving a multipart/encrypted body part, the following
  381.    sequence of steps describes the processing necessary to decrypt the
  382.    enclosed data.  It must be emphasized that these steps are
  383.    descriptive, not prescriptive, and in no way impose restrictions or
  384.    requirements on implementations of this specification.
  385.  
  386.    (1)  The second body part and the control information in the first body
  387.         part must be prepared for the decryption process according to the
  388.         value of the protocol parameter.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Galvin, et al               Standards Track                     [Page 7]
  395.  
  396. RFC 1847                  Security Multiparts               October 1995
  397.  
  398.  
  399.    (2)  The prepared body parts must be made available to the decryption
  400.         process according to a local convention.  The decryption process
  401.         must make available to the MIME implementation the result of the
  402.         decryption and the decrypted form of the encrypted body part.
  403.  
  404.             NOTE: The result of the decryption process is likely to
  405.             include a testament of the success or failure of the
  406.             decryption.  Failure may be due to an inability to locate
  407.             the proper decryption key or the proper recipient field,
  408.             etc.  Implementors should note that the data, if any, of a
  409.             failed decryption process is pretty much guaranteed to be
  410.             garbage.
  411.  
  412.    (3)  The result of the decryption process is made available to the user
  413.         and the MIME implementation continues processing with the decrypted
  414.         body part, i.e., the body part returned by the decryption process.
  415.  
  416.             NOTE: A MIME implementation will not be able to display the
  417.             received form of the second body part because the
  418.             application of encryption will transform the body part.
  419.             This transformation will not be described in the MIME
  420.             headers (Content-Type: and Content-Transfer-Encoding:) but,
  421.             rather, will be described in the content of the first body
  422.             part.  Therefore, an implementation should wait until the
  423.             encryption has been removed before attempting to display
  424.             the content.
  425.  
  426.    The following example is an illustration of a multipart/encrypted
  427.    body part.  It is necessarily incomplete since the control
  428.    information is defined by the security protocol, which must be
  429.    specified in a separate document.
  430.  
  431.     Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
  432.             boundary="Encrypted Boundary"
  433.  
  434.     --Encrypted Boundary
  435.     Content-Type: TYPE/STYPE
  436.  
  437.     CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
  438.  
  439.     --Encrypted Boundary
  440.     Content-Type: application/octet-stream
  441.  
  442.         Content-Type: text/plain; charset="us-ascii"
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Galvin, et al               Standards Track                     [Page 8]
  451.  
  452. RFC 1847                  Security Multiparts               October 1995
  453.  
  454.  
  455.         All of this indented text, including the indented headers,
  456.         would be unreadable since it would have been encrypted by
  457.         the protocol "TYPE/STYPE".  Also, this encrypted data could
  458.         be any type of data, labeled accordingly, of course.
  459.  
  460.     --Encrypted Boundary--
  461.  
  462. 3.  Definition of Control Information Content Types
  463.  
  464.    This document defines a framework within which security services may
  465.    be applied to MIME body parts.  A minimal MIME implementation will be
  466.    able to recognize multipart/signed and multipart/encrypted body parts
  467.    and be able to identify the protected data and control information
  468.    body parts within them.
  469.  
  470.    Complete support for security services requires the MIME agent to
  471.    recognize the value of the protocol parameter and to continue
  472.    processing based on its value.  The value of the protocol parameter
  473.    is the same value used to label the content type of the control
  474.    information.
  475.  
  476.    The value of the protocol parameter and the resulting processing
  477.    required must be specified in the document defining the security
  478.    protocol used.  That document must also precisely specify the
  479.    contents of the control information body part.
  480.  
  481. 4.  Definition of Key Management Content Types
  482.  
  483.    This specification recognizes that the complete specification of a
  484.    MIME-based security protocol must include a mechanism for
  485.    distributing the cryptographic material used in support of the
  486.    security services.  For example, a digital signature service
  487.    implemented with asymmetric cryptography requires that a signer's
  488.    public key be available to the signee.
  489.  
  490.    One possible mechanism for distributing cryptographic material is to
  491.    define two additional body parts: one for the purpose of requesting
  492.    cryptographic information and one for the purpose of returning the
  493.    cryptographic information requested.  The specification of a security
  494.    protocol may include a definition of two such body parts or it may
  495.    specify an alternate mechanism for the distribution of cryptographic
  496.    material.
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Galvin, et al               Standards Track                     [Page 9]
  507.  
  508. RFC 1847                  Security Multiparts               October 1995
  509.  
  510.  
  511. 5.  Security Considerations
  512.  
  513.    This specification describes an enhancement to MIME to support signed
  514.    and encrypted body parts.  In that context this entire document is
  515.    about security.
  516.  
  517. 6.  Acknowledgements
  518.  
  519.    David H. Crocker suggested the use of a multipart structure for the
  520.    MIME and PEM interaction.
  521.  
  522. 7.  References
  523.  
  524.    [1] Crocker, D., "Standard for the Format of ARPA Internet Text
  525.        Messages", STD 11, RFC 822, University of Delaware, August 1982.
  526.  
  527.    [2] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
  528.        Extension) Part One: Mechanisms for Specifying and Describing the
  529.        Format of Internet Message Bodies", RFC 1521, Bellcore and
  530.        Innosoft, September 1993.
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Galvin, et al               Standards Track                    [Page 10]
  563.  
  564. RFC 1847                  Security Multiparts               October 1995
  565.  
  566.  
  567. 8.  Authors' Addresses
  568.  
  569.    Jim Galvin
  570.    Trusted Information Systems
  571.    3060 Washington Road
  572.    Glenwood, MD  21738
  573.  
  574.    Phone: +1 301 854 6889
  575.    Fax: +1 301 854 5363
  576.    EMail:  galvin@tis.com
  577.  
  578.  
  579.    Sandy Murphy
  580.    Trusted Information Systems
  581.    3060 Washington Road
  582.    Glenwood, MD  21738
  583.  
  584.    Phone: +1 301 854 6889
  585.    Fax: +1 301 854 5363
  586.    EMail:  sandy@tis.com
  587.  
  588.  
  589.    Steve Crocker
  590.    CyberCash, Inc.
  591.    2086 Hunters Crest Way
  592.    Vienna, VA 22181
  593.  
  594.    Phone::    +1 703 620 1222
  595.    Fax:    +1 703 391 2651
  596.    EMail:  crocker@cybercash.com
  597.  
  598.  
  599.    Ned Freed
  600.    Innosoft International, Inc.
  601.    1050 East Garvey Avenue South
  602.    West Covina, CA 91790
  603.  
  604.    Phone: +1 818 919 3600
  605.    Fax: +1 818 919 3614
  606.    EMail:  ned@innosoft.com
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Galvin, et al               Standards Track                    [Page 11]
  619.  
  620.